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INTRODUCTION 

Beginning with the U.S. weapon system develop- 
ment programs of the 1950’s, there has been a trend 
in our increasingly complicated technological society 
to undertake fewer but much larger and more com- 
prehensive programs. The National Aeronautics and 
Space Administration's Apollo Program and, more 
recently, the Space Shuttle, are examples of this 
growth in program magnitude and complexity. 

Although the Apollo Program goal was clear, to 
reach it required the use of rapidly developing 
technology that was based on rapidly increasing 
scientific ^owledge. It required the organization to 
be highly flexible, and it was changed when unex- 
peaed developments made it necessary. As a 
measure of the magnitude of the Apollo Program, 
staffing at its peak grew to 390 000 workers in in- 
dustry, 33 000 in NASA Centers and 10 000 in 
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universities. By 1969, the year of the first lunar lan- 
ding, total staffing had been reduced by 190 000. By 
1974, it was down to 126 000 (ref. 1). 

Enormous as the Apollo effort was and as the 
Space Shuttle Program is, such programs may be 
viewed as only forerunners of future national pro- 
grams that will be even larger and more complex. 
Examples of the macrotrends that confront the 
future programs are shown in figures 1 to 5. Al- 
though these trends depict aerospace industry pro- 
ducts, they arc generally applicable to large pro- 
grams other high technology industries. 

The complexity of the systems have almost gone 
beyond the point of human grasp (fig. 1). In fact, 
today, the computer is taking control of many of the 
traditional management functions relating to the 
flow of the millions of parts that must converge into 
the final system. And scheduling the work of 
thousands of people has become a computer func- 
tion in many areas. 
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greater risk, investment cost, and scope. The greater 
risk in turn drives the decision-making process into 
the generation and evaluation of a much greater 
number of alternative solutions as the decision tree is 
worked. 

Figure 4 shows the accelerating trend of engineer- 
ing development costs that result from increasing 
program complexity. The decreasing produaion 
costs result from increased experience and more 
detailed analysis, design, and development. 

In the aerospace business the number of test ar- 
ticles (fig. 5) available for flight testing has con- 
tinually decreased because of the enormous cost and 
sophistication of each succeeding generation. For ex- 
ample, at present, only four Space Shuttle craft arc 
budgeted. 

These macrotrends arc not all-inclusive but 
generally give a taste of the harsh flavors that can be 
cxpcrtcd. The increasingly complex decision matrix 
is unfortunately worked in an exponentially decreas- 
ing time frame. 


Macrocosts in billions of dollars vs. years from go- 
ahead for three NASA programs arc shown in figure 
2. The curves dramatize the exponential cost in- 
creases and extended periods of time required as the 
programs become more complex and broader in 
scope. The total cost estimate for the Space Shuttle 
design, development, test, and evaluation (DDT 
& E) program is now 6.18 billion (1971 dollars). 

The increasing engineering manpower as a func- 
tion of time required for analysis and documentation 
and for design is shown in figure 3. Although both 
curves arc shown exponentially increasing, the 
analysis and documentation investment inacases at 
a greater rate than the design functions. This trend 
can be attributed to program objeaives involving 
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AN APPROACH TO MANAGING LARGE, 
COMPLEX PROGRAMS 

The work of management can be defined as mak- 
ing decisions in terms of the activities of planning, 
organizing, staffing, controlling, and directing the 
allocation of scarce resources to achieve the organiza- 
tional goals, usually with poor management infor- 
mation. A proliferation of theories exists as to how 
these management activities should be carried out, 
and tons of literature exist on concepts such as 
authority, responsibility, span of control, and single 
reporting (refs. 2 and 3). Most of these principles arc 
related to so-called vertical management, that is, 
management charancrized by organization along 



Figure i 


2 






the traditional pattern of the hierarchical chart in 
which authority and responsibility flow downward 
and information and glory upward. 

Critics of vertical management point out that the 
work to be performed flows horizontally across the 
organization chart and that the hierarchical struc- 
ture, by fostering parochialism, creates barriers to 
communications and can actually impede the pro- 
gress of a program. To overcome these problems, 
some mechanism for lateral management is needed. 
The most common attempt at a solution is to 
superimpose a horizontal program management ac- 
tivity over the vertical framework to draw upon and 
coordinate selected skills and services present in the 
hierarchy (refs. 4 and 5). 

In the 1960’s people began to seriously apply the 
systems approach to the management of large, com- 
plex programs. The objective was uncompromisingly 
complete coverage of the program management 
endeavor. Staning with an analysis of the functions 
necessary to carry out a given program, a model was 
defined, a matrix of responsibility assigiunents was 
prepared, and each operational process was ex- 
amined in detail to establish how it was to be carried 
out and how it was related to all other processes. 
Planning for implementation of this management 
tool was started in 1967 (ref. 6). 

As applied to program management, the systems 
concept may be viewed as an organized approach to 
attaining program objectives by defining and struc- 
turing all elements involved in such a way as to form 
a single system whose constituent parts are united by 
some form of interaction (fig. 6). The systems 
management approach is a method of objectively 
considering flows through an organization, with an 
information feedback system supplying quantitative 
information about the flows, so that decisions can be 
made to manage the flows to attain the greatest 


payoff relative to organizational goab. And this ac- 
tivity takes place in an active environment, not a 
vacuum. The word objectively is a key to the 
usefulness of the approach. Nowhere is this more 
evident than in functional analysis, a process fun- 
damental to the concept. 


MANAGEMENT PHASES 

Because of the immense complexity and large 
costs of today’s macrosystems, they typically must 
last for many years. Also, before the huge in- 
vestments that are required arc committed, many 
studies are made and much debate takes place. All 
levels of society may become involved in the sorting 
out process, including national and local. The 
government is highly involved, except in very 
isolated cases. Typical of a macrosystem currently in 
the gestation stage is the MX program. The Depan- 
ment of Defense (DOD) has studied survival basing 
modes and missile configurations for many years. A 
national debate at all levels of government is now 
underway. 

Both the DOD and NASA have found it desirable 
to formalize the life cycle of typical macrosystems. 
The details differ between DOD and NASA, but the 
general concepts are identical. Figure 7 shows the life 
cycle of a typical macrosystem. During the concep- 
tual phase, the mission is defined, requirements are 
established, alternative approaches are evaluated, 
and advanced development takes place, usually for 
the pacing high technologies. 

In the definition phase a design baseline is 
established, performance specifications arc drafted, 
and detailed development plans arc formulated. The 
go-ahead for development is preceded by formal 
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high-level government reviews, which are endorsed 
by the Administration and Congress. These formal 
reviews are required because large expenditures are 
committed when full-scale development is ap- 
proved. The development phase consists of design, 
test, and production prototypes of the full-scale 
macrosystem. 

In the operational phase full-scale production and 
operational employment are underway. Main- 
tenance concepts are implemented; logistics, in- 
cluding spares and support, are activated; training 
takes place at all levels of the operation; and produa 
improvements based on operational experience are 
evaluated and implemented when desirable. Need- 
less to say, once in the operational phase, a macro- 
system can consume huge resources. Any mistakes 
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not uncovered in previous phases can be very costly 
indeed — not only in terms of money and manpower, 
but also in terms of operational capability. 

The divestment phase is less precise, since many 
systems seem to live on forever, at least portions of 
them. The DOD can phase a weapon system out of 
the Force Stmeture, but the same system may be 
utilized by the National Guard, or by foreign allies, 
long afterwards. Therefore, the items associated with 
divestment shown in figure 7 often do not take place 
completely. Ideally, there would be a phase-down, a 
transfer of resources, and a formal critique. 

Over the years, formal management phases have 
been developed for both DOD and NASA, although 
again, the two agencies differ in detail. Figure 8 
shows typical program management phases, which 
include contract phases, and some formal customer 
reviews. Formal baselines are established at certain 
points in the management phases, and these are 
documented by formal systems specifications to pro- 
vide a basis for conuactual negotiations, change con- 
trol, and formal reviews. 

In order to formalize the management process, 
system management procedures have been gen- 
erated over the years. These are constantly changing 
as more experience is accumulated. Some typical 
procedures are shown in figure 9, along with 
associated objectives. These procedures have 
multiplied over the years so that today large 
organizations exist just to cope with the formal re- 
quirements of major systems. The paperwork 
associated with compliance can be astounding! 


PLANNING ROADMAP 

An overall rationale for planning a complex, high- 
technology program is illustrated in figure 10. The 
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scheme can be generalized so that it is applicable to 
any program with deliverable end items. G>nsid- 
crablc effort was devoted to structuring the process 
by North American Aviation, Inc., (now Rockwell 
International Corporation) during the development 
of Apollo (refs. 1 and 6). Because of the immense 
complexity of the Apollo Program, systematic plan- 
ning was essential for success. 

It should be emphasized that the procedure 
outlined in figure 10 is not another new manage- 
ment scheme — there are indeed too many of these 
buried in the literature. Rather, it is an orderly 
mechanism for planning a complex program out of 
which will fall the traditional products which must 
be generated before project initiation such as a Work 
Breakdown Structure, Program Plan, Reliability 
Plan, Master Program Schedule, Material Review 
Procedures, etc. 

As discussed previously, there are essentially four 
management phases in most large aerospace pro- 
grams, viz., conceptual, definition, development, 
and operational. The planning roadmap of figure 10 
must be generated for each of these phases, especial- 
ly for large programs. Good planning is most critical 
for the development and operational phases where 
most of the resources are expended. Illustrative ex- 
amples given in this paper are associated with the 
development phase. 

As shown in figure 10, the initial planning process 
starts with the generation of functional flows. These 
define the work to be done, either in series or in 
parallel, to fulfill the program requirement. The 
work is defined to a level low enough that first-line 
supervision can assume meaningful tasks. This plan- 
ning process is analogous to the generating of the 
Work Breakdown Structure, although by proper for- 
malization other planning products will emerge and 
the opportunity for good program and functional 
management will present itself. Also, generation of 
functional flows can be generalized so that a plan- 
ning baseline can be established which is applicable 
to any program. Generalized functional flows have 
been produced (ref. 6). They are extremely useful 
tools in attacking the planning of new programs — a 
difficult, very creative endeavor. 

Once generalized functional flows have been 
generated, each activity is assigned to an organiza- 
tion element. At this point, generality can be 
preserved, as is the case in this paper, or organiza- 
tional peculiarities can be introduced to fit a given 
program or organization. In any case, the rationale is 
applicable whether or not universality is retained. 

After responsibility has been assigned to all tasks, 
operational process charts can be produced. These 
are generated for the functional organization, in- 
dependent of program organizational structure. The 
need for matrix management now becomes evident 
since programs are end-item oriented, and the func- 
tional organization used to accomplish interim tasks 


is of little consequence to the program manager. 

After the generation of the program tasks and 
assignment to organizational elements, task require- 
ment sheets can be produced. Because the functional 
flows were generated in enough detail for first-line 
supervision, these sheets can be given to each 
organizational unit for planning purposes. They 
constitute the baseline definition of the work to be 
performed and schedules to be met, and specify in- 
terfaces with other organizational elements. 

At this point, the end-item-oriented program 
manager comes into play. He can generate in- 
tegrating process charts for each end item or interim 
product of interest. The final platming product will 
be the definition of each activity, organizational 
responsibility, interfaces, and products leading to 
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the end item. Integrating process charts arc in- 
valuable tools for project engineers who must track 
and forecast cost, s^edule, and performance bogies. 


FUNCTIONAL FLOW 

Functional analysis is predicated on the precept 
that, before a decision is made as to how to do 
something, a careful look should be taken at what 
is to be done. An innocent-appearing proposi- 
tion — until examination reveals that we habitually 
confuse what with how and that the consequences of 
this confusion can be disastrous. The systems ap- 
proach seeks to develop a way of thinking, a view- 


point, a conceptual framework, together with a 
methodology for implementation. 

The rationale for generating functional flow is 
shown in flgtire 11. Major functions necessary to 
fulfill a program requirement arc defined. Seven 
major funnions arc sufficient for the development 
phase of most aerospace programs or contracts. Each 
major funnion is then broken down into increas- 
ingly finer structure until meaningful tasks arc 
defined at the level of first-line supervision. Three 
levels arc generally sufficient to meet this criterion. 
In some cases it is necessary to go to the fourth level. 
It is convenient to formalize the numbering process 
as shown in figure 11. The desirability of this for- 
malization will become evident as we progress. 

In executing the development phase of a program, 
it is assumed that the Advanced Systems people have 
captured the program. Therefore, the task before us 
is one of execution — whether it is building a little 
red wheelbarrow or delivering a Space Shutde Or- 
bitcr. Therefore, in figure 12 the task of “Capturing 
the Program’’ is dotted. The remaining six funaions 
arc arranged in scries or in parallel, depending on 
whether the output from preceding fiinctions is 
necessary for execution. The arrangement of figure 
12 has been applicable to most major aerospace pro- 
grams. The ultimate objective, of course, is to 
demonsuate program or contract compliance. 

The first-level function, “Determine Re- 
quirements,’’ is further broken down in figure 13, 
and the second-level function, “Prepare Program 
Plans,’’ is cascaded to a third level, as shown in 
figure 14. As mentioned above, it is the author’s ex- 
perience that detail at the third level, and occa- 
sionally at the fourth level, is sufficient to define the 
work for first-line supervision. 


THIRD LEVEL 
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RESPONSIBILITY ASSIGNMENT MATRIX 

Each function at the third or fourth level, must 
now be assigned to an organizational element for ex- 
ecution. In aerospace, 12 entities can accomplish a 
complex program, viz.: 

Plans & Programs (P) 

Configuration Management (C) 

System Engineering (S) 

Test Operations (T) 

Design Engineering (E) 

Logistics (L) 

Procurement (M) 

Facilities PQ 
Manufacturing (F) 

Data Management (B) 

Quality Assurance (Q) 

Contract Administration (A) 

(To formalize the planning process, it is convenient 



to assign letters to each of these organizational en- 
tities as indicated.) 

For a given organization, these entities may be 
grouped or contained within organizational 
elements. It is generally advantageous to proceed 
with the planning process in a generalized fashion, 
independent of organizational peculiarities which, 
in most cases, arc transient. The tasks which emanate 
from the planning process can then be given to ex- 
isting functional organizational elements, or alter- 
natively, organizational deficiencies will become 
evident. 

Each third or fourth-level function is now assigned 
as a primary task to one of the 12 organizational en- 
tities listed above. It should be emphasized that only 
one organizational entity has prime responsibility for 
each task, although support may be required from 
other organizational entities. The procedure for 
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responsibility assignment is shown in figure 15. The 
letter P denotes prime responsibility and the letter S, 
support. For example, the third-level fiinmon, 
“Review Plans & Revise Schedule” is the prime 
responsibility of the organizational entity. Plans & 
Programs, with support from System Engineering, 
Procurement, Manufacturing, etc. 


OPERATIONAL PROCESS CHARTS 

At this point it is necessary to formalize certain 
definitions peculiar to the plaiuiing process as shown 
in figure 16. Since all programs are end-item 
oriented, each function must be end-item oriented. 
Thus, it is not sufficient to define a design function. 



Figure 17 


7 







8 


ORIGINAL. IS 

OF POOR QUAIJTY 


«P.7.5 1««. A2,5.l9h. 





TASK REQUIREMENT SHEET 


—.j.. p. Prepare Preliminary 

Ertgineering Dev Plan 
REF. 2.5.15a 

PRIMARY: System Engineering (S) 
SUPPORT. A, B, C, L, M, T, X 


TASK 

DESCRIPTION 

INPUTS 

OUTPUTS 















- 















— 




U'" 




Figure 19 


which is functionally oriented, but to define, in ad- 
dition, the objea to be designed. This difference 
between program management and functional 
management constitutes the basis for matrix 
management. Thus, an activity (projea) is a tran- 
sient verb requiring an object. K function is the ac- 
tivity plus the object. We will now discuss functional 
flows which arc structured functions, and processes 
which arc funaional flows plus inputs and outputs. 

In order for the first-line supervision to perform a 
given task, it is necessary that he or she obtain inputs 
from other organizations. These inputs must be 
documented. For example, it is not sufficient that a 
test be performed; the documented results of the 
test must be available for others to accomplish their 
tasks. In formalized program or project planning, in- 
puts, or formalized documentation can be identified 
as requirements for the accomplishment of each 
function. The source of these inputs can be iden- 
tified, both from an organizational and task view- 
point. In figure 17, for example, the first-line super- 
visor who has the responsibility for the function, 
“Prepare Program Plan,” needs inputs from 
organizational entities such as. Plans & Programs (P) 
and System Engineering (S). His outputs, again, 
documented results of his efiforts, go to other 
organizational elements as inputs to fiinaions. 
Finally, an operational process is generated which is 
composed of structured funaions along with their 
associated inputs and outputs. Typical operational 
process charts arc shown in figure 18. Note the 
crossflow of inputs and outputs. Generalized opera- 
tional processes for the 12 organizational entities 
listed previously have been stmetured for the Defini- 
tion and Development phases of program manage- 
ment (ref. 6). These have proven to be invaluable in 
planning complex programs. 


TASK REQUIREMENT SHEETS 

Once the functions have been defined and in- 
puts/outputs identified, it is now relatively simple 
to produce Task Requirement Sheets. These sheets 
can be given to first-line supervision as planning 
guides and as tools for managing projea respon- 
sibilities. Figure 19 is an outline of a Task Require- 
ment Sheet. The fourth-level function, 2.j.l3a 
“Prepare Preliminary Engineering Development 
Plan,” is assigned to the organizational element. 
System Engineering (S), as prime. Support is re- 
quired from Contract Administration (A), Data 
Management (B), Configuration Management (C), 
Logistics (L), Procurement (M), Test Operations (T), 
and Facilities (X). The task description is a detailed 
outline of the function, “Prepare Engineering 
Development Plan.” Inputs arc the documented 
results of the tasks performed by other organiza- 
tions; they constitute the outputs from other func- 
tions. In mm, the outputs from this function, that 
is, the documented results of this task, will con- 
stitute inputs to other functions. 


INTEGRATING PROCESS CHARTS 

Until now, we have dealt with planning a complex 
program, defining tasks, and assigning them to 
elements of a traditional funaiond organization. 
Over the yean, projea engineen and program 
managers have emerged in aerospace industry 
because of the complexity of programs. Project 
engineers have traditionally been hard-nosed people 
who chased end-items through the complex maze of 
large, cumbersome, burcauaatic organizations. 
Often, they have no line authority, but use friend- 
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-7 PRELIMINARY INTEGRATED TEST 
OPERATIONS FACILITY/SPECIAL 
TEST EOUIPMENT/SUPPORT EQUIP- 
MENT/ENO ITEM MAINTENANCE 
SUPPORT REQUIREMENTS (T2.S.14b) 
-8 preliminary DEFINITION OF TEST 
OPERATIONS SPECIAL TEST EQUIP- 
MENT (T25.I4W 

-9 PRELIMINARY TEST OPERATIONS 
TECHNICAL/ADMINISTRATIVE SITE 
SUPPORT REQUIREMENTS (T2.5.14b) 
•tOPRELIMlNARY INTEGRATED TEST 
OPERATIONS END ITEM TEST TIME- 
LINES IT2.S.14b> 


-1 PRELIMINARY TEST OPERATIONS 
PLAN (T2.5.14C. S2.5.14b) 

PLAN INCLUDES: 

MAJOR END ITEM TEST PLAN PER 
WORK BREAKDOWN STRUCTURE 
PRESHIPMENT CHECKOUT PLANS 
DEVELOPMENT/FLIGHT QUALIFI- 
CATION TEST PLAN 
FLIGHT -READY, LAUNCH POST- 
FLIGHT OPERATIONS PLAN 
IDENTIFIES END-TO-END ACTIVI- 
TIES FOR: 

FACILITY SURVEILLANCE 
ENO ITEM SUPPORT EQUIPMENT 
INSTALLATION SEQUENCE 
END ITEM SUPPORT EQUIPMENT 
TEST SEQUENCE 
ENO ITEM SUPPORT EQUIPMENT 
INTEGRATED TEST SEQUENCE 
END ITEM FLIGHT VEHICLE TEST 
SEQUENCE 

END ITEM FLIGHT VEHICLE 
INTEGRATED TEST SEQUENCE 


Figure 21 
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)R PROGRAM TEST PLAN 



VIEW ALL PLANS AND PREPARE 
ELIMINARY PLAN REVISION 
OUIREMENTS FOR DEVELOPMENT 


PREPARE FINAL INTEGRATED TEST 
OPERATIONS ANALYSIS 


PREPARE FINAL TEST OPERATIONS 
PLAN 


PREPARE FINAL PROGRAM TEST PLAN 

PJ,4,7 


T2.8.14C 


T2.5.l4d 


S2.5.t4c 

1 


lEUMINARY PROGRAM PLANNING -t TEST OPERATIONS PLAN OUTLINE 
iCKAGE AND REVISION REQUIRE- <T2.S.14d> 

ENTS<S2.S.14c.T2.S.14d) -2 TEST OBJECTIVE SUPPORT REQUIRE- 

MENTS MATRIX (T2.S.14d> 

-3TEST TRADE STUDY REPORT 
(T2.5.14d) 

-4 ALTERNATE TEST APPROACHES 
(T2.5.14dl 

-6 FINAL INTEGRATED TEST OPERA- 
TIONS FACILITY/SUPPORT EQUIP- 
MENT INSTALLATION AND CHECK- 
OUT REQUIREMENTS (T2.S.I4dl 
>6 FINAL INTEGRATED TEST OPERA- 
TIONS FACILITY/SUPPORT EQUIP- 
MENT INSTALLATION AND CHECK- 
OUT TIMELINES IT2.5.14d) 

-7 FINAL INTEGRATED TEST OPERATIONS 
FACILITY/SPECIAL TEST EQUIPMENT/ 
SUPPORT EQUIPMENT/ENO ITEM 
MAINTENANCE SUPPORT REQUIRE- 
MENTS (T2.S.14d) 

-8 FINAL DEFINITION OF TEST OPER- 
ATIONS SPECIAL TEST EQUIPMENT 
(T.2.5.14dl 

-9 FINAL TEST OPERATIONS TECHNI- 
CAL/AOMINISTRATIVE SITE SUPPORT 
REQUIREMENT (T2.5.14d) 

-10 FINAL INTEGRATED TEST OPERA- 
TIONS END ITEM TEST TIMELINES 
(T2.5.14d) 


-1 FINAL TEST OPERATIONS TEST 
PLAN (S2£.14c1 


S-SYSTEM ENGINEERING 
T-TEST OPERATIONS 
P-PLANS AND PROGRAMS 
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ship, persuasion, threats, embarrassment, or 
whatever tactics arc necessary to push their end-items 
through the system. The best project engineer has 
usually been the toughest, loudest, and most obnox- 
ious of the lot. 

With the advent of macrosystems, the ad hoc pro- 
ject engineer has been replaced by matrix manage- 
ment. This concept is maiiifcstcd in many forms, in- 
cluding powerful project organizations reponing to 
the program manager or a single coordinator who 
collects the status of end-items based on inputs from 
functional managers. The tools for cfifcctivc manage- 
ment of end-items can be easily developed from the 
concepts outlined above. 

Since the planning process is end-item oriented, 
one only needs to identify the end-item of interest 
and trace its path through the operational process 
charts already generated. In figure 20, for example, 
the identified end-item, “Program Plan,” is an out- 
put from the third-level function, “Prepare Program 
Plan,” which is performed in the organizational en- 
tity, Plans & Programs (P). To prepare the program 
plan, inputs, such as Engineering Development 
Plan, arc required. The Engineering Development 
Plan is generated from the function, “Prepare Engi- 
neering Development Plan,” which is performed in 
System Engineering (S). In order to prepare the 
Engineering Development Plan, a Preliminary Pro- 
gram Plan is required as an input. 

Integrating Process Charts can be prepared for 
each end-item of interest. The inputs and outputs 
needed to generate the end-items can be identified, 
organizational interfaces defined, and schedules laid 
out for the projea engineer. Generalized Integrating 
Process Chans can be made for end-items which arc 
traditionally imponant to the program manager, 
such as the final Program Plan. However, for most 



Figure 22 



programs, it is necessary to make Integrating Process 
Charts which arc peculiar to a particular program or 
project. An example of an Integrating Process Chan 
is shown in figure 21. The chan shows some of the 
activities of Systems Engineering (S), Test Opera- 
tions (T) and Plans and Programs (P) along with in- 
puts and outputs leading to the final program test 
plan. 

In lieu of good projea planning, the conuol room 
was bom to track the stanis of end-items of interest 
to upper management. Some of these control rooms 
have indeed been sights to behold with magnetic 
boards, brilliant colors, and even flashing lights. But 
when the planning behind these end-items is probed 
in depth, it often becomes evident that there is little 
or no substance. How many projea hours could be 
saved with a little forward planning! 


MATRIX MANAGEMENT 

The planning roadmap of figure 10 has generated 
Operational Process Charts for the ^nctional 
organization and Integrating Process Charts for the 
program management organizations. These plan- 
ning tools are illustrated in figure 22. Only certain 
end-items arc of interest to the program manager 
(such as those shown in fig. 23). In addition to pro- 
jea management responsibilities, the fiinaional 
organizations must retain expertise in several 
disciplines, generate long-range plans to maintain 
the enterprise, operate facilities, prepare for future 
projects, ttc. Thus, the functional organization must 
be responsible for long-range corporate health, while 
the program managers are concerned with their end- 
items to satisfy the immediate customers (fig. 23). 
Upper management must be sensitive to the motives 
of both functional and program management and 
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Figure 24 


balance priorities accordingly. Even organizations 
such as NASA arc concerned with these conflicting 
motivations. In NASA, for example, the Space Shut- 
tle is an important program that requires the support 
of all the NASA centers. On the other hand, the 
long-range health of the Agency must be preserved 
for the post-Shuttlc era. 

A mixed program and functional or matrix 
organization (fig. 24) is generally the preferred struc- 
ture for the aerospace industry with its large, com- 
plex programs and rigid cost, schedule, and perfor- 
mance standards. Both the program and functional 
groups benefit. The program is emphasized by 
designating one individual as a focal point for all 
matters pertaining to it. Manpower utilization is 
flexible and cost-effective because a reservoir of 
specialists is maintained in functional organizations 
and is employed by the program only when needed. 
Specialized knowledge is available to all programs, 
and the transfer of knowledge and experience among 
programs takes place through the function^ 
organization. Projea people have a functional 
home. Responsiveness to program needs and 


customer desires is generally faster than for purely 
functional or for purely project organizations. 
Management consistency among programs and pro- 
jects can be maintained. A balance among cost, 
schedule, and performance can be obtained for up- 
per management through built-in checks and 
balances. 

The establishment of a matrix organization is no 
panacea (refs. 7 and 8), and conflicts will constantly 
arise between program or project and functional 
groups. The tendency of upper management is to 
support the program since the program needs affect 
this years profit, or this years budget, or this years 
customer. “Head Mothers” or functional managers 
need to be supported for the corporate good. The 
first step is insisting on good program baselines so 
that both functional and program management can 
accomplish adequate planning. An easy but painful 
alternative is to react to immediate problems, leav- 
ing both corporate and customer needs unsatisfied. 
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